05 - 选型与落地
前置：不需要。本篇是全专题结论，可独立阅读。
本篇回答：什么情况下根本不需要沙箱、需要时该选哪条隔离路线、以及最容易被漏掉的出口管控怎么落地。
本篇会用到的词：
| 词 | 意思 |
|---|---|
| 执行面 | 系统里「会真 的把某段内容跑起来」的位置。判断树的第一个问题问的就是它存不存在 |
| 多租户 | 多个互不信任的用户共用同一套基础设施。一旦多租户，隔离强度的要求就上一个台阶 |
| KVM / 嵌套虚拟化 | 硬件虚拟化支持。宿主给不给，直接决定了 microVM 这条路走不走得通 |
| 出口代理 | 沙箱唯一的网络出口，所有外发流量都经过它，由它比对白名单后放行或拒绝 |
| 纵深防御 | 不指望任何单一防线拦住一切，而是叠加多层，让攻击者必须连续突破。沙箱是其中一层，不是全部 |
一、选型判据
1.1 那个最容易被跳过的分支
图里 Q1B 那一支值得单独说 ：即使 Agent 完全不生成代码，只要装了第三方 MCP Server，你就已经在运行不可信代码了。
那段代码是 MCP Server 的实现，跑在你的进程里、用你的身份、能读你的文件。Agent 安全 · 工具投毒拆过它能做什么。
很多团队的心智模型是「我们没做 code interpreter，所以不需要沙箱」—— 这个推理在接入 MCP 之后就不成立了。
二、自建还是托管
| 自建 | 托管 | |
|---|---|---|
| 前置条件 | 需要 KVM 才能用 microVM，普通云主机多数不支持 | 无 |
| 冷启动 | 走「启动 → 初始化 → 装依赖」，秒级起步 | 快照恢复，03 篇 |
| 数据边界 | 代码不出自己的环境 | 代码和数据交给第三方 |
| 运维 | 镜像、节点池、清理、监控全自建 | 无 |
| 成本模型 | 固定成本为主 | 按用量，峰值贵 |
2.1 KVM 这道门槛
自建 microVM 沙箱最先撞上的不是技术难度，是云厂商的虚拟机实例多数不支持嵌套虚拟化。可选项只有裸金属实例或明确支持嵌套虚拟化的机型，两者都更贵。
这解释了为什么托管沙箱服务能成立 —— 它卖的不只是软件，还有「已经解决了 KVM 问题的机器」。
2.2 数据边界通常是决定性的
如果 Agent 会接触到用户上传的文档、内部代码库、生产数据，那么「这些内容要发到第三方沙箱服务」往往过不了合规。
这一条经常比性能和成本更早决定结论。 建议在选型讨论的第一轮就问清楚，不要在做完性能对比后才发现方向不对。
三、网络出口：最容易漏的一环
01 篇 3.1 节已经指出：文件系统和内核隔离做得再好，只要沙箱能访问任意外网，读到的数据就能发走。
3.1 白名单出口的落地
实现位置有两个选择：
| 位置 | 优 点 | 缺点 |
|---|---|---|
| 沙箱内代理 | 能看到应用层信息，可做 TLS 检查 | 沙箱内的代码理论上可绕过它直连 |
| 宿主侧网络策略 | 沙箱内无法绕过 | 只能按 IP / 域名判断 |
推荐两层都做：宿主侧用网络策略兜底（沙箱只能访问代理），沙箱内代理做细粒度判断和审计。04 篇里 Suna 的双层代理正是这个结构。
3.2 白名单的实际维护成本
会比预想的高。pip install 一个包可能触发对多个 CDN 域名的访问，npm 更甚。实践上的折中：
- 包管理器源用固定的私有镜像（同时解决速度和白名单问题）
- 业务需要的外部 API 逐个报备
- 保留一个「申请开通」的流程，而不是让开发者卡在这里
四、沙箱在纵深防御里的位置
沙箱不是一道能独立成立的防线。把 Agent 安全 · 防线在哪一层的结论接上：
| 威胁 | 沙箱 | 需要配合的层 |
|---|---|---|
| 破坏宿主文件 | ✅ | — |
| 提权到宿主 | ✅ | — |
| 占满资源 | ✅ | — |
| 数据外传 | ❌ | 网络出口管控 |
| 提示注入导致越权操作 | ❌ | 工具级授权（MCP 网关） |
| 恶意 MCP Server | 部分 | 供应链检查（工具投毒） |
只做沙箱的平台，在提示注入下仍然会交出数据 —— 因为那段代码在沙箱里跑得完全合法。
五、落地清单
从零搭建时的顺序，按性价比排：
| 顺序 | 做什么 | 解决 |
|---|---|---|
| 1 | 容器隔离 ＋ 非 root 用户 ＋ 只读根文件系统 | 挡住绝大多数误操作 |
| 2 | 网络白名单出口 | 挡住数据外传，性价比最高的一步 |
| 3 | 资源配额（CPU / 内存 / 时长 / 磁盘） | 挡住资源耗尽 |
| 4 | 会话级生命周期 ＋ 到期清理 | 状态可用，且不会无限堆积 |
| 5 | 换 gVisor 或 microVM | 挡住内核逃逸 |
| 6 | 快照加速冷启动 | 体验优化，非安全项 |
第 2 步经常被排到最后，但它应该在第 2 位 —— 内核逃逸需要一个可利用的漏洞，而数据外传只需要一行 requests.post。
六、全专题结论
1. 隔离的边界由谁实现，决定了它的强度。 容器的隔离由宿主内核实现，所以内核漏洞即逃逸；microVM 由硬件虚拟化实现；gVisor 把系统调用拦在用户态。三者是三个不同的信任假设，不是三档性能。
2. 冷启动优化的终局是不启动。 快照把「启动 → 初始化 → 装依赖」整条路径绕过去，代价落在存储上。
3. 宿主不应具备伸进沙箱的能力。 E2B 的 envd 和 Suna 的 sandbox-agent-server 是两个独立项目收敛到的同一个解 —— 沙箱内跑代理服务，宿主只走协议接口。
4. 沙箱管不了数据外泄。 这是本专题最重要的一条。网络出口管控与工具级授权不是可选补充，是与沙箱同等必要的两层。
← 回到 专题索引 · Agent Infra 板块总览